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Conditional Branching in FileMaker Scripts 


By Bob Vallejo 

I have developed, out of necessity, a method to exe¬ 
cute conditional scripts in FileMaker Pro. It lets me 
accomplish tasks that I could not easily do otherwise. 
While this technique should be described as a work¬ 
around, it is reliable and does not rely on undocu¬ 
mented features. 

I was designing a complex database system for 
key control at UC Berkeley (both conventional metal 
keys and electronic card keys). I hit the wall in the 
later phases of the design because of the inability to 
execute conditional scripts. A call to Claris Tech 
Support revealed not only that they did not know a 
method for making a conditional branch, but also 
that I was just one of many users who had expressed 
such a need. 

I 

The Idea 

Down but not out, I spent a few hours experiment¬ 
ing and brainstorming to develop the method de¬ 


scribed in this article. What we want to do is outlined 
in Figure la on page 2. But an acceptable alternative 
is the subset shown in Figure lb and is what is possi¬ 
ble for us today in FileMaker. 

With this technique you can execute as many 
conditional scripts as you like or as you can stand. It 
does not seem to have a special impact on speed. As 
with any script, execution can be slow, depending on 
the operations you have scripted and how many 
steps are included. I am using this system with data¬ 
bases that have up to 4000 records and the execution 
time of three consecutive conditional scripts is ac¬ 
ceptable to me on a Centris 610. 

But note that to the extent this technique makes 
it easier to string together several scripts, each ac¬ 
complishing, say, a complex task, execution times 
could get long. In return, error-free automation is 
available — you’ll have to decide for yourself the 
value of the tradeoff. 

The technique described in this article can be 
retrofitted to existing databases without difficulty. 
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The Ingredients 

The first essential item to understand is 
that FileMaker can execute multiple scripts in 
sequence. Within one script you can add a 
Perform Script step that causes another script 
to be executed (even a script in another file). 
When the second script is complete, execution 
returns to the next step of the first script. We’ll 
make good use of this feature. 

Another characteristic to remember is that 
FileMaker always goes to the earliest entered 
record in an unsorted found subset. This 
proves to be useful. Caution: FileMaker does 
not necessarily go to the first entered record 
following a Find All command — it goes to the 
current record, that is, the record that was 
active just before the command. 

In looking through all the available script 
commands you will notice that there is a script 
step that does make a branching decision, even 
although it is a specialized one. The Go to Next 
Record/Request step (and the mirror step Go 
to Previous Record/Request) includes an 
option labelled “Exit script after last” (see Fig¬ 
ure 2). With this Exit option on, the step de¬ 
cides if the current record is the last in the set 
or not and performs a different action depend¬ 
ing on the answer. It is designed to allow a 
script to repeat itself once for each record in a 
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Figure 1 


found set and then stop when it has processed 
the last record. But we are going to use it a little 
differently. 

The trick is to devise a way to exploit this 
decision-making step in other ways than in¬ 
tended; that is, to execute or not execute por¬ 
tions of a script. Since the Exit option only 
allows us to leave or not leave a script, our task 
evolves into figuring out a way to continue with 
a script or to leave it (Figure lb), and possibly 


Editor's Note 

While the latest version of FileMaker Scripting is quite powerful, a few additional features are 
needed to make it more capable in execution and/or more efficient to set up. My guess is that Claris is 
working on this and I hope we’ll see something soon. 

One needed item is the ability to specify a conditional branch within a script. That is, to make a 
script step that decides which subsequent steps to execute based on a data value in a field. Conditional 
scripts would expand the kinds of problems that we can solve. While there is potential messiness in¬ 
volved in adding built-in conditional branching to FileMaker scripts, I expect that Claris will fill this 
hole someday and that they’ll probably make nice for us. 

Meanwhile, there are a couple of tricks that can be used as work-arounds that accomplish effec¬ 
tive conditional scripting. Bob Vallejo has come up with a clever and creative technique that I have 
not seen elsewhere. Very nice, very productive. 
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* Go to Layout [" 1) Data Entry "] 

* Find All 

* Go to Record/Request [No dialog, 1 ] 

* Copy [Select, " AdvisoryScriptControl' 1 '] 
t Enter Find Mode [] 

* Paste [Select, "RecordNumber "] 

* Perform Find [] 

* Go to Next Record/Request [Exit script after last] 

* Omit 

$ Go to Layout [" AdvisoryLayoutPointer "] 

* Pause/Resume Script 






Options. 

R] Exit script after last 


Figure 2 


execute another script instead. To do so we are 
going to manipulate the number of records 
observed by the Exit option. 

In turn, for the trick to work a basic restric¬ 
tion is introduced: there must always be at least 
two records in the database. (Not to worry: 
most databases should qualify!) The first two 
records need to be entered manually before the 
scripts described below are exercised. 

The Setup 

In many of my database designs I reserve 
the first record for data entry. I call this the 
buffer record. There are many good reasons 
for using this strategy—one is to make the 
execution of conditional scripts as easy as pos¬ 
sible; another is to have the option of making 
lookups active on only the buffer record. This 
is useful in preventing accidental corruption of 
information by triggering a lookup when edit¬ 
ing permanently-entered records later on. 

I also number my layouts and scripts in 
their natural created order. This pays big divi¬ 
dends if you ever have to do a database recover 
operation, which restores layouts and scripts 
back to their as-created order. In other words, 
if you have rearranged your layouts and scripts 
in a custom order, they will slip back to their 
as-created order after a Recover operation. 


Numbering of layouts and scripts is also useful 
when giving phone help since you can refer to a 
layout or script by a number rather than an 
ambiguous name. Many of my databases have 
up to 15 layouts and 50 scripts. 

| 

| 

The Demo 

1 

Let’s now look at creating a simple data¬ 
base that will illustrate the concepts involved in 
achieving a conditional script. This demo data¬ 
base will use two conditional scripts. One will 
alert the data entry person if an attempt is made 
to permanently enter a blank record. The other 
will automatically either duplicate a valid buff¬ 
er record and then clear all the buffer fields, 
or prevent permanent entry if the buffer is 
blank and retain the original buffer contents 
for further editing. Each depends on making a 
decision about the existence of data in the 
buffer record. 

Create a database with the following fields, 
layouts and scripts: 

Fields - 

1 ) A RecordNumber field with records num¬ 
bered starting from zero in natural entry order, 
and with RecordNumber zero assigned to the 
first record (which is used as the buffer record). 
Set field options for “a serial number” and 

| “prohibit modification of auto-entered values”. 

2) Text field “Last Name” 

3) Text field “First Name” 

Of course, in a real application there would 
likely be more fields for entry of data. 

4) A calculation field AdvisoryLayoutPointer 
with a text result: 

= If (LName = "" or FName = "2", "1") 

5) A calculation field AdvisoryScriptControl 
with a text result: 

$ 

| = If (LName = "" or FName = "<=1", "<=0") 

:§ 

6) A calculation field EntryScriptControl with 
a text result: 
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= If (LName ="" or FName =”<=0", "<=1") 

While the results of the two calculations 
may seem odd, you’ll see that what we are do¬ 
ing is generating a parameter to be used within 
a Find request. Sneaky. 

Layouts - 

1) Data Entry 

All fields may be included on this layout. 
Some fields not concerned with data entry may 
be placed off the visible screen. Also on this 
layout is a button designed to activate the C) 
Master Script Sequence script. 

2) Advisory message: “buffer fields LName 
and FName must be filled in before permanent 
entry is allowed”. Also on this layout is a but¬ 
ton designed to activate the D) Return to buff¬ 
er script. No fields are present on this layout. 

Scripts - 

The italic line numbers in the script de¬ 
scriptions below are not part of the real script. 
They are reference points to make description 
easier. 

A) Test Buffer for Validity 

Line 1 Go to Layout, [ 1) Data Entry] 

Line 2 Find All 

Line 3 Go to Record/Request [No dialog, 1] 
Line 4 Copy [select entire contents, “Advisory- 
ScriptControl”] 

Line 5 Enter Find Mode 
Line 6 Paste [Select entire contents, “Record- 
Number”] 

Line 7 Perform Find 

Line 8 Go to Next record/Request [Exit script 
after last] 

Line 9 Omit 

Line 10 Go to Layout, layout number given by 
field: “AdvisoryLayoutPointer” 

Line 11 Pause/Resume Script 

After Line 3 we are at record number 0 
which is the buffer record. Line 6 pastes the 


contents of the AdvisoryScriptControl field 
previously copied in Line 4. The Find in Line 7 
will return either two records or one record 
depending on the contents of the Advisory¬ 
ScriptControl field from Line 4. If there are 
two records, the active one will be the second 
one since it was created after the first. 

It is at Line 8 that the critical decision is 
made. Note that if Line 8 brings back two 
records the succeeding Lines 9,10, and 11 will 
continue to execute. But if one record is the 
result of Line 8 then the script will exit and no 
further steps in this script will be executed. 

For the script to get to Line 9 the buffer 
record fields must have been incomplete and 
the field AdvisoryScriptControl calculation 
must have contained “<= 1 ” when copied in 
Line 4. Following the Omit in Line 9 we are 
back in the buffer record, just where we need 
to be. 

After Line 11 we are looking at layout 2) 
which is telling the data entry person that 
“Both LName and FName must be filled in 
before this record can be permanently en¬ 
tered”. This layout has a button that is defined 
to Pause/Resume Script and another button 
that is used for escape if a wrong turn is made. 

B) Conditionally Enter Record 

Line 1 Go to Layout [ 1) Data Entry] 

Line 2 Find All 

Line 3 Go to Record Request [No dialog, 
Request 1 ] 

Line 4 Copy [select entire contents, “Entry- 
ScriptControl”] 

Line 5 Enter Find Mode 
Line 6 Paste [select entire contents, “Record- 
Number”] 

Line 7 Perform Find 

Line 8 Go to Next record/Request [Exit script 
after last] 

Line 9 Omit 

Line 10 Duplicate Record/Request 
Line 11 Omit 
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Line 12 Clear, select entire contents, “FName” 
Line 13 Clear, select entire contents, “LName” 
Line 14 Go to Field, “LName” 

After Line 3 we are at RecordNumber 0, 
the buffer record. Line 6 pastes the contents 
of EntryScriptControl previously copied in 
Line 4. Line 7 will return either two records or 
one record depending on the contents of the 
field EntryScriptControl in Line 4. 

Line 8 decides whether to proceed or to 
exit. If two records came back, the succeeding 
script lines will continue to execute; if one 
record was returned the script will exit at Line 8 
and no further script lines in this script will be 
executed. 

For the script to get to Line 9 the buffer 
record fields must have been complete, the 
field EntryScriptControl, as a result, must 
have contained “<=1”. Following this Omit 
command we are back in the buffer record, 
just where we need to be! 

Line 10 duplicates the now-validated buff¬ 
er record so that it becomes part of the accept¬ 
ed set of entered records. Line 11 omits the 
duped record leaving us back at the buffer 
record. Line 12 and Line 13 clear the two data 
entry fields to prepare for another entry. Line 
14 positions the cursor so it is ready for typing. 

C) MasterScriptSequence 

Line 1 Go to Layout, [1) Data Entry] 

Line 2 Perform Script [sub scripts, “A) Test 
Buffer for Validity”] 

Line 3 Perform Script [sub scripts, 

“B) Conditionally Enter Record”] 

This script ties the previous two together to 
manage the data entry process. Line 2 tests the 
buffer for validity. If the buffer contents are 
OK, the script aborts and then Line 3 is execut¬ 
ed. Otherwise an advisory message is displayed. 

Line 3 tests the buffer for validity. If the 
buffer is not OK the script is aborted. If it is 


OK, the buffer is duplicated and the user 
fields in buffer are cleared. 

Please note that if scripts A) or B) are in an 
external file, it may be necessary to add a step 
after Line 2 and/or Line 3 to bring execution 
back to the file where the C) Master Script 
Sequence lives. 

Examination of scripts A) and B) will re¬ 
veal that when either of these scripts is execut¬ 
ed the first seven steps will always return a 
subset of records consisting of one record (Re¬ 
cordNumber 0) or two records (RecordNum¬ 
ber 0 and RecordNumber 1). The next step 
“Go to Next Record Request [Exit script after 
last] will then do one of two things. If the first 
seven steps brought back one record the script 
will now terminate and go back to the Master¬ 
ScriptSequence. If the first seven steps, on the 
other hand, brought back two records the 
script will continue and will execute all remain¬ 
ing lines of the script and then return to the C) 
MasterScriptSequence. This means that we 
have achieved control of the scripts by the 
contents of AdvisoryScriptControl and 
EntryScriptControl. It can now be seen that 
the scripts are truly controllable and there is no 
limit to what conditions you can factor into the 
calculation fields AdvisoryScriptControl and 
EntryScriptControl. A natural progression 
from this example would be to have a self¬ 
lookup field which would be used to warn if a 
record already exists and if so bring up another 
advisory layout and inhibit entry of the poten¬ 
tial duplicate. 

The script C) MasterScriptSequence when 
run will achieve the following equivalent nested 
If functions within the script commands: 

If the data entry record is complete, perma¬ 
nently enter it; otherwise, display the advisory 
message; end the script. 

Another script is needed to solve a problem 
with this particular implementation. Note that 
when getting the advisory message the operator 
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is supposed to click “continue”, either using 
the status area button or a layout button creat¬ 
ed for that purpose. But some operators have 
been known to switch to Browse mode in¬ 
stead. But once in Browse and out of Script 
mode, “continue” is no longer available and 
the operator is stuck. Thus this script: 

D) Return to buffer 

Line 1 Find All 

Line 2 Go to Record/Request [No dialog, 1] 
Line 3 Go to Layout, [1) Data Entry] 

Line 4 Enter Browse Mode 
Line 5 Go to Field, “LName” 

The Payoff 

Using conditional scripting I have con¬ 
structed database systems that can automati¬ 


cally check data entry conditions, as above. But 
I’ve also used the technique to automatically 
decide if another database reference file needs 
to be updated or a new record created, and in 
other ways. Having the ability to control a 
script from the results of a calculation (and the 
equation can be a quite sophisticated one if 
necessary) is a very powerful new tool that I am 
enjoying! 

Bob Vallejo is a Senior Engineer with the 
University of California at Berkeley and works for 
the Department of Molecular and Cell Biology. 
He has been designing FileMaker databases since 
1988. Some designs include key control, workshop 
service invoicing, equipment inventory and 
tracking, service vendor contracts, personnel job 
cards, performance evaluations, and so forth. 
He can be reached at 510-642-2467 or EMail 
Bob_Vallejo@MAILLINK.Berkeley.EDU 


Click ’n Type: Writing with a Mouse 


By Dr. Mark Alberhasky 


iVtodern day life for many of us has become 
the cliched existence where “there are simply 
not enough hours in the day.” I work in such 
an environment, and find the computer an 
invaluable tool in addressing a never-ending 
mountain of work. 

In my medical specialty, Pathology, the 
generation of reports for patient specimens has 
been a daily litany of dictation, secretarial tran¬ 
scription, proofing, and finally printing of the 
completed document. Like any profession, 
elements of this task are routine, which in many 
instances produces reports which are extreme¬ 
ly similar if not identical. However, the details 
of two similar patient specimens often vary 
enough that attempts to edit boilerplate text 
can be as burdensome for the transcriptionist 


as typing from scratch. Even in circumstances 
where a transcriptionist might be able to rely 
on editing a text template, I still must dictate 
the changes to be made and proof-read the 
document (after waiting for the transcription 
to be completed). With practical voice recog¬ 
nition looming on the horizon, this process 
will certainly be revolutionized, but undoubt¬ 
edly at considerable cost. 

Feeling that there had to be a way to im¬ 
prove on the classical transcription process 
(without spending heavy bucks on a voice 
recognition system), I developed a technique 
for creation of text documents which is some¬ 
what novel, flexible, and very useful for me. 

I stumbled on the idea for this technique 
one day when “old” text, still on the clipboard, 
was accidentally pasted into the body of a re¬ 
port, expanding an existing sentence (albeit 
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with inappropriate verbiage). It occurred to me 
that small building blocks of text could be 
stored in fields, linked to scripted buttons that 
would copy the text from a given field and 
paste it into another. With two or three clicks 
on specific buttons I could construct complete 
sentences and paragraphs. 

I split the task into two files: one to serve as 
the text block generator, the other to hold the 
reports. The blocks built by the Click ’N Type 
generator are moved over to the file which 
contains the final report documents. The text 
generator is yet another test of the operating 
envelope of FileMaker Pro as it makes exten¬ 
sive use of fields, buttons, and scripts. To pro¬ 
vide adequate flexibility in the construction of 
demanding and precise text descriptions — the 
basic underpinning of a Pathology report — I 

Figure 1 


knew I had to provide access to numerous text 
snippets. This meant lots of fields and buttons 
(and therefore lots of scripts) arranged in a 
structure which gives the user a pattern to fol¬ 
low in creation of the text block. 

I considered building the text pieces into 
scripts (in Paste Literal commands), but that 
would have made future editing of the text 
more difficult. I decided instead to store the 
text in conventional, and editable, fields. 

I constructed a file with 160 snippet fields, 
plus several miscellaneous fields for holding 
other data, and included a “merge” field where 
all the pasted snippets are combined. I then 
created 160 buttons, and (groan) wrote 160 
scripts, each of which defined the Copy opera¬ 
tion from a specific snippet field and the Paste 
operation into the “merge” field. Then I 



GENERATOR 


micro/edit 




brush lul i; Carina 


lecords 


[jjjutoA 

••aitoiiv 


j( .11 MMMHMMRMI : 

■ t {• ' : ' ■ ■: : • < 

I,*"’"’""*** - *****"’"’"*" .. . . .... .1 

ji ■mmRnnMiMMi jj MMIMBBBBNI i 


' * * * a 1 




SaiBdr 


[designated bronchial brushing RUL reveal benign squamous cells. Some of the 
squamous cells show nuclear irregularity and hyperchromasia consistent with 
moderate dysplasia. No diagnostic carcinoma is demonstrated. 


Brows# 


elements I 


neoplasm 


SECTIONS REVEAL 
HYPERPLASTIC 
LYMPHOID TISSUE 
PARTIALLY SURFACED 
BY SQUAMOUS AND 
RESPIRATORY 
EPITHELIA CONSISTENT 


smear(s) i! 


bai.t 


cutosp ;l pleural 

MIMlijM M t A MW * > VUlAlUIUUUIUll 

cb 


brush nos \\ brush 111 

• M MMIM I HI M M MI M U ' > MMUMtUUMIMIIMH 

.rnainstm 


ct fna tracheal 


..!......... Jj MMaMfMMWHMtMl j 




fflfiLSflUflSS 


Dx | Undo] Cleatj _j 


The FileMaker Report *©1994 Elk Horn Publishing • Issue 61 • Page 7 
























































































































































designed a layout structure that arranged the 
scripted buttons into groups of 10 (Figure 1). 

The first draft of the design quickly dem¬ 
onstrated both the viability of the concept and 
the shortcomings of the initial effort. The file 
holds many different records, each loaded with 
text snippets that create a report for a specific 
type of specimen (i.e. one record for a stomach 
biopsy report, another for skin biopsy). As 
such, I could not simply label the buttons with 
the name of the associated text snippet, which 
must change from record to record. The an¬ 
swer was to (more groan) create 160 label fields 
corresponding to each text snippet field. By 
taking advantage of the layers available in Lay¬ 
out (using Send to front and Send to back 
commands), I was able to superimpose a trans¬ 
parent button on top of each label text field 
placed in the back layer (Figure 2). To the user 
in the Browse mode, the button looks like a 
regular text-labeled button. When they click it, 
however, they are actually clicking the trans¬ 
parent button in the front layer, activating the 
linked script which then copies and pastes the 
associated text snippet into the merge field. 
Whew! 

The beauty of this design is that the text 
labels for every button change effortlessly from 
record to record, providing incredible flexibili¬ 
ty. A little work with this prototype led to one 
more addition (or, dare I say it, 160 more but¬ 
tons and scripts): the creation of a thin “edit” 
button under text labels (visible as a dark hori¬ 
zontal bar in Figure 1) which switches layouts 
and goes to the specific field where the actual 
text snippet is stored as well as the associated 
label field (Figure 3). This lets the user edit the 
stored text in an instant for easy “on the fly” 
maintenance and updating of the database. 

For those still counting, the final tally for 
my file structure is around 340 fields, 360 but¬ 
tons, and 360 scripts. I should explain to the 
faint of heart that I used QuicKeys macros 
executed in the Define Fields and ScriptMaker 


windows to semi-automate the creation of all 
these elements. So it was not quite as Fler- 
culean a task as it may sound. 

Armed with a really useful shell, all that 
remains is to fill in the blanks. One must at this 
point critically examine the text structure of the 
chosen topic. Unlike free-form writing (this 
article, for example), which is non-repetitive, 
many business and professional documents are 
inherently repetitive from report to report. 

Whether consciously or unconsciously, many 
such documents also follow a relatively strict 
order in their composition, usually to ensure 
completeness. Documents in which you can 
recognize this sort of pattern can be adapted to 
the Click ’n Type format. 

In essence, you create sentences that are 
structured grammatically so that for given 
sections (opening, middle, closing) inter¬ 
changeable snippets can be combined in a 
manner that results in a valid statement. For 
example, consider the opening sentence in a ^ ^ 
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Figure 3 


letter sent from a customer service representa¬ 
tive, “You wrote our department last week 
concerning a bad experience you had with one 
of our products.” The choices for how this 
sentence could be dissected and broken into 
snippets could include: “You” (You, Your 
wife, Your son, Your daughter, Your husband, 
Your mother, Your employer), “wrote” (wrote, 
called, faxed, contacted, queried), “bad experi¬ 
ence” (bad experience, positive experience, 
embarrassing experience). With three clicks 
you create a fairly specific sentence which will 
always be correctly spelled and formatted, with 
little or no need for proof reading. And it will 
be “transcribed” the moment you click it out— 
“real-time transcription”!. 

Getting to and from the Generator file is 


the last order of business. Scripts automate the 
process, switching between the document file 
(where you begin and end) and the Generator, 
copying and pasting along the way. 

I begin by copying the patient name, and 
moving to a Main Menu layout in the Genera¬ 
tor file. Since there isn’t a “go to external lay¬ 
out command, this move is accomplished by 
writing a single-step Go to Layout (Main 
Menu) script in the generator file. The main 
menu has a button for each record in the file. 
Scripts linked to each button perform a Find 
(to select the correct individual record), Paste 
the name data in its field, and then clear any 
previous text from the merge field that may 
remain from the last time the record was used. 
After assembling the merge text block, a similar 
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script copies the block and switches back to the 
document file. The final script (in the docu¬ 
ment file) pastes the merged text into the desti¬ 
nation field. 

Since every record in your file can contain 
unique data elements (comprehensively tai¬ 
lored to fit a variety of circumstances) you will 
eventually, as you use and edit and expand it, 
create a text generator with great flexibility. I 
often produce 40 to 60 report documents in a 
day. In the past this meant dictation of numer¬ 
ous routine repetitive reports, a delay for the 


transcription, and a proof-reading session to 
correct the inevitable misinterpretations, spell¬ 
ing and formatting errors which are unaccept¬ 
able in a medical report. My new FileMaker 
system saves wear and tear on my vocal cords, 
speeds creation of finalized reports, wins kudos 
from the medical transcription department 
whose workload has been decreased in the 
process. It also creates a little more time for me 
to attack the other stuff crowding my desk. 

*-V- 


Techniques & Tips & Notes 


❖ Wholesale UK Phone Number Conversion 
By Dick Williams 

AMSYS Technology, Surrey, England 

phoneday is the 16th April 1995! From 
that day all UK telephone area codes will 
change. An 081 number in London, for exam¬ 
ple, will change to 0181, an 071 number in 
London will change to 0171, and an 0883 num¬ 
ber in Caterham will change to 01883. 

There are also new codes for five major 
cities. The area code will change completely, 
and a 2 or a 9 will be added before local 6 digit 
numbers. The five cities are: 

Leeds 

(0532) xxxxxx becomes (0113) 2xxxxxx 
Sheffield 

(0742) xxxxxx becomes (0114) 2xxxxxx 
Nottingham 

(0602) xxxxxx becomes (0115) 9xxxxxx 
Leicester 

(0533) xxxxxx becomes (0116) 2xxxxxx 
Bristol 

(0272) xxxxxx becomes (0117) 9xxxxxx 


Additionally, the international access code 
will change from 010 to 00, i.e. access numbers 
in the USA change from 0101 to 001 and other 
overseas numbers change from 010 to 00. 

The new area codes can be used now to dial 
numbers. 

We have a large FileMaker file that con¬ 
tains five different telephone number fields. 

We needed a way to convert all numbers in all 
records to the new versions. A FileMaker equa¬ 
tion is a good way to accomplish this. It saves 
lots of manual work and makes all the conver¬ 
sions consistent. 

Once we had an equation that worked, we 
just created five new calculated phone fields 
and pasted it into each one in turn. It took 10 
hours to do the whole conversion from old 
numbers to new on a Quadra 650 which is our 
FileMaker Pro Server! 

The FileMaker calculation we used to con¬ 
vert the old style UK telephone numbers to the 
new style numbers looks like this: 
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NewNum = If (Left (Phone Num, 3) = "081", "01" & 

Middle (Phone Num, 2, Length (Phone Num) -1), 

If (Left (Phone Num, 3) = "071", "01" & 

Middle (Phone Num, 2, Length (Phone Num) -1), 

If (Left (Phone Num, 4) = "0532", "0113 2” & 

Middle (Phone Num,6,Length (Phone Num) -9) &""& 

Right (Phone Num, 4), If (Left (Phone Num, 4) = "0742”, 
"0114 2" & Middle (Phone Num,6, Length (Phone Num) -9) & 
"" & Right (Phone Num, 4), If (Left (Phone Num,4) = "0602", 
"0115 9" & Middle (Phone Num, 6, Length (Phone Num) -9) 

&"" & Right (Phone Num, 4), If (Left (Phone Num, 4) = 
"0533", "0116 2" & Middle (Phone Num, 6, 

Length (Phone Num) -9) &" 11 & Right (Phone Num,4), If 
(Left (Phone Num,4) = "0272", "0117 9" & Middle (Phone 
Num, 6, Length (Phone Num) -9) &"" & Right (Phone Num, 
4), If (Left (Phone Num, 3) = "010", "00" & Middle (Phone 
Num, 4, Length (Phone Num)-2), If (Left (Phone Num, 1) = 
"0”, "01" & Middle (Phone Num, 2, Length (Phone Num) -1), 
Phone Num))))))))) . 


❖ Display Different Messages in Browse/Preview 
By Ken Jones 

You can give users of your FileMaker Pro 

| 

databases different instruction messages de¬ 
pending on whether they are browsing or pre¬ 
viewing data. The trick is to create two different 
layout text messages with a fill (not text color) 
of the background color (usually white) of the 
message area. Figure 1 shows Layout and both 
messages. 

Designate the message for Browse mode as 
a non-printing object (in the Slide Objects 
dialog box) and place it directly on top of the 
message for Preview mode. Make sure the 
Browse mode message completely covers the 
preview mode message (Figure 2). 

When you preview the screen, the Browse 
mode message is made invisible, uncovering 
the Preview message (Figure 3). 
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❖ Instant T-Squares 
By Ken Jones 

While fine-tuning a layout you may notice 
an object that appears out of alignment with 
the rest of the objects of the same group. In 
Figure 1 (on page 12), the “Sold” label appears 
slightly higher than “Quant” and other labels. 

Is it time to pull out the T-Squares? File¬ 
Maker’s magnetic horizontal and vertical T- 
Squares, with their snap-to-it characteristics, 
are great for precision alignment of layout 
objects. However, if both T-Square lines are 
close to the intended destination of the object 
being moved, they both may grab the object, 
preventing it from arriving at the position that 
you intended (Figure 2, page 12). 

Before bringing out the T-Squares, you can 
use a selection rectangle to get a quick check of 
the vertical or horizontal alignment of the sus¬ 
pect object in relation to the other objects of 
the group (Figure 3, page 12). 

In Figure 3,1 began the selection rectangle 
in a clear blank space below and to the right of 
the “Sold” field. Then I dragged the pointer up 
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and to the left until the top edge of the selection 
rectangle just touched the bottom of the 
“Quant” label. Suspicions confirmed!- the 
“Sold” label is indeed higher than the rest of 
the labels in the header. It only takes a couple 
of seconds to drag a rectangle and check the 
alignment. You might want to use Show... 

Text Boxes in order to better define the objects 
you are trying to align. 

Make an educated guess of the number of 
pixels the object needs to be moved, then 
nudge it into position with an arrow key and 
check again. If necessary you can still bring out 
the T-Squares and snap the object to one of 
them, but if not necessary, this is quicker. 

*-V* 

Ken Jones is a FileMaker consultant living on the 
island of Kauai, Hawaii. He can be reached at 
(808) 823-6871, Fax (808) 823-8880. 
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FileMaker vs ‘Relational’ Databases 


By Joe Kroeger 

Over the years there has been an on-going 
background drizzle of articles and discussions 
about relational databases vs flat-file databases. 
The theme has usually embodied a sneering 
and condescending attitude toward ‘flat-file’ 
databases coupled with an air of superiority 
about the ‘obvious’ virtues of‘relational prod¬ 
ucts’. I’m here to say that this mind set is just 
not justified. And that it is time we stand up 
more assertively for the FileMaker’s virtues. 


The subject of this article is a little afield from 
those that we normally run. But my dander was 
up! To help compensate we’ve added four extra 
pages to this issue. 


Yes, yes — I admit that I am biased in favor 
of FileMaker. So read on with that in mind, 
examine the evidence and arguments, then 
make your own decision. But please note that I 
am biased by choice and after long experience. 
(I would not still be writing The FileMaker 
Report were I not convinced that FileMaker is 
excellent. Sure, there are a few shortcomings, 
and sure, I have some quibbles with FileMaker 
and with Claris. But relative to relationals I’ve 
seen, it is clearly superior.) 

The proximate trigger for this current dis¬ 
cussion (tirade?) appeared in the December ’94 
issue of Mac User. The article is called “The 
Database Dilemma” and purports to present 
the case for switching a design to a relational 
database from a flat-file database. It presents 
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Article Summary 

Authors Bruce Onder and Jeffrey Sullivan make all these points in their text: 

This article shows how to tell if a relational design is for you. How to make the switch. Example ‘flat- 
file programs: FileMaker and Panorama. They are easy to set up and easy to use. But some tasks may 
seem awkward or the files may be getting too large or too slow in flat-file implementations. Maybe it is 
time to switch to a relational database. 

• Telltale signs that a relational structure is needed: (1) use of replicated fields in a record, (2) time 
wasted entering the same data over and over, (3) file is getting too big and too slow. 

• Some improvements can be made, such as using the FileMaker lookup operation. These kinds of 
eatures are called pseudo-relational but are not as powerful as true relational features. 

• Biggest advantage of a relational database is that it is not limited to a single record structure where all 
recoids have the same set of fields. Multiple linked tables are used instead, each like a flat-file with its own 
structure. Breaking a database down into small linked tables makes the relational structure more efficient. 

• Rich and complex programming in relationals allows much more sophisticated data integration. 

• In an order-entry example the flat-file version can waste space - there is room in a record for five 
items but fewer maybe ordered. Unused fields will still take up allocated space. When more than five 
items are ordered, another record is needed with space wasted duplicating some of the order data. 

• Printing forms from multiple records tends to make them look unprofessional due to blank fields 
and duplicated records. 

• With a relational structure only the data in linking fields is repeated, re-keying customer data is not 
needed, and linked information can appear together in a report form. 

• Before making the switch to a relational structure be sure to evaluate the time and money needed. 

Use of an existing template, if available, can be a big savings. Otherwise there is a significant investment to 
be made in buying the relational database program, programming a new design, training the users, and 
allowing for future fixes and changes. 

• If you are not already a database programmer it will take some time to learn the product selected 
and to learn relational modeling. This can be a good investment if more databases will be created in the 
future and if you want to maintain and improve them yourself. 

For simply converting an existing flat database it might be best to hire someone to implement a new 
version. This can be more efficient than bringing yourself up to speed. But you will need to manage the 
project and the relationship with the programmer - bids, specs, progressive stages, bug testing, and so 
forth. 

Switching to a relational database is no light task, but if you are frustrated with your current system, 
the change may save you money, make your office run more smoothly, and preserve your sanity.” 


' 836888 « 8 " $ 


the latest glaring example of the attitude de¬ 
scribed above. MacUser put the article in the 
“Hands On Power Tools” section. The sidebars 
“Article Summary” and “Article Figure” on the 
following pages present my paraphrase of the 
article and its associated figure. 


Defining Terms 

You can see from the precis of the article 
that there are several topics to be discussed. But 
first some definitions are in order so that we 
know what we are talking about. 

There are, of course, flat-file databases that 
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Figure Summary 

The figure accompanying the article makes these further points: 

• The flat-file portion shows two records in an order-entry file. Each record contains three groups of 
fields: customer information, order information, and order items. The records have room for five or¬ 
dered items, but the example order is for six items - thus another record is needed for the sixth item. The 
customer information and order information in the second record are labelled as “Repeated informa¬ 
tion” and the order items section is labelled “Wasted space”. 

• The relational example is described as more flexible and efficient than the flat-file system since it can 
accommodate any number of ordered items, doesn’t allocate unneeded space, and little data is duplicat¬ 
ed. “ In a flat-file database, there’s no way to accommodate a variable number of items per order without 
wasting space and possibly repeating data unnecessarily.” 

• The relational portion of the figure shows the same information organization except in separate 
tables: one for customer information, one for order information, and one for each of the ordered items. 
The labelling of the customer table and the order table says “Enter this data only once per customer, not 
for each order.” The order items table* is labelled “You can have as few or as many items as you want 
without wasting space.” 

In addition to the main body of the article and the figure, there is a box titled “Choosing the Right 
Database Program” that very briefly outlines five programs: 

• 4th Dimension — Mac-only but Windows version planned; good for multiuser workgroups; com¬ 
piler, runtime, server versions available. 

• 4D First — Single-user; for flat-file users who would like to develop their own databases; a less ex¬ 
pensive way to build unsophisticated databases. 

• FoxPro for Macintosh — Multiplatform multiuser; for workgroups and offices, developers tend to 
be from DOS/Windows side. 

• Helix Express — Mac-only; unique graphic programming interface; may be difficult to accomplish 
sophisticated requirements. 

• Omnis 7 — Cross platform; For client/server environments; not for tight budgets. 

* Actually, the relational part of the figure is a little imprecise. Is there a different table for each item or¬ 
dered, as implied by multiple linkage fields, or is there one table that expands and contacts, accordion- 
style, in which case one link field might suffice? 


do indeed have quite modest capabilities. They 
may be good for simple tasks like address lists 
— their most common application—but other¬ 
wise tend to be either feature-shy or designed 
for very specialized applications, such as part of 
a personal information manager set. 

The other end of the spectrum is where the 
“relational” databases live. It is not clear exactly 
what it takes to qualify officially for this appela- 


tion. There are scholarly books that define the 
term in such detail that few, if any, would qual¬ 
ify, even among large main-frame databases. 
On our personal computers several programs 
define themselves as ‘relational’ anyway. I 
think of them, at the overview level, as largely 
“Application Generators”. That is, they are 
designed to be used by experienced program¬ 
mers to build stand-alone solutions for specific 
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How About a Better Example? 

My suggestion to the relational proponents is that they should pick a better example than the tired 
old customer-addresses-and-many-line-items-in-invoices demonstration. Databases have not needed 
redundant data keying since the long-ago days of punched cards. Lookups work great and are easy to 
implement. Repeating fields can handle a large number of line items on an order. 

Why do the authors feel the need to create a fallacious example? I don’t mind discussing the pros and 
cons on the basis of actuality, but it is irksome indeed to be faced with complaints that don’t apply. I have 
come to expect such poor examples from the relational competition. A series of ads not long ago from the 
supplier of a relational database used a similar example. It was wrong then and remains wrong now. 




end-user problems. As such, they usually re¬ 
quire detailed programming of features and 
operations, and they often allow such things as 
customized menus. 

But notice that there are also products at 
other locations than these two extremes. Some 
Application Generators have many features 
stripped out and pre-designed layouts and 
procedures stripped-in. (All in attempts to 
make them easier to use and to compete, on 
the Mac side, with the market leader: FileMak¬ 
er.) Some low-end databases have gradually 
added features, attempting to augment their 
meager capabilities. 

Where does FileMaker live along this spec¬ 
trum? I think it is more than a flat-file database, 
and has been for quite a while. Lookups have 
for years given FileMaker users half of a fully 
bidirectional link between files with different 
data organizations. This has made me reluctant 
to refer to FileMaker as ‘flat-file’. I have for 
some time been using the term ‘hierarchical’ to 
describe a FileMaker type of database. And 
with the recent advent of improved FileMaker 
scripting, we have been able to make the links 
between files effectively bidirectional, remov¬ 
ing another functional barrier and allowing 
FileMaker to serve even more applications. 

So I think there is a range of products start¬ 
ing with dedicated (but often quite serviceable) 
databases at one end, hierarchical databases at 


places in the middle, and Application Genera¬ 
tors near the other end. 

Article Critique 

Part of the problem I have with the article is 
the hidden (unconscious?) and subliminal 
agenda that abounds. Does placing the article 
in the Power Tools section of the magazine 
imply that FileMaker and Panorama are not 
power tools? The box called “Choosing the 
Right Database Program” does not include 
FileMaker or Panorama as options, so they 
seem to never be the ‘right’ choice. Assertions, 
especially in the figure, about some types of 
databases are taken as distinguishing character¬ 
istics when in fact they are not essential and not 
even true. Creating a straw-man flat-file target 
and then imbuing FileMaker and Panorama 
with those supposed characteristics is igno¬ 
rance at best and perhaps a dash of intellectual 
dishonesty. 

Actually, if‘flat-file’ designs did what the 
article says they do, the authors might have a 
point. But they don’t so they don’t. 

The author’s telltale signs (see second bul¬ 
let in “Article Summary”) that your flat-file 
data may be begging for a relational structure 
are easily demolished. First, I think they are 
untrue, and second, even if they were true, it 
can easily be a small price to pay for the other 
advantages of FileMaker. 
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| Two Hierarchical Architectures 

| FileMaker and Panorama have many similarities and a few differences. Both are looked down upon 
by the relational snobs as being ‘merely’ flat-file. But both have quite substantial capabilities built-in that 
f do not require procedure programming by the user. Some of the distinctive characteristics of the two are 

derived from their underlying architecture. Both can be regarded as hierarchical database programs. 

The original FileMaker designers came up with a scheme for a unified index for the contents of all 
| fields that forms the core of the database. Thus it is that FileMaker automatically indexes all entries. This 
| in turn makes many operations (like finding and sorting) fast on all fields without active user interven- 

j tion during set up. Drawbacks: slow importing since all incoming data must be indexed, and larger files 
| since the index takes up room. 

The underlying Panorama (ProVue Development, Huntington Beach CA, 714-841-7779) design 

| 

| takes an entirely different direction. Panorama does not index anything—instead it is RAM-based. This 
means that the whole database content is loaded into memory at one time. Thus indexing is not required 
since operations on non-indexed data are very fast. It also means that files are quite small and that some 
convenient operations (like temporary calculations on a subset of the records) are easily available. Poten¬ 
tial drawback: the amount of data that can be handled at once is limited by the RAM available. 

I 


(1) Nobody uses replicated fields in a record 
except when that design choice provides other 
advantages. The authors seem to think that in a 
FileMaker order-entry design we would use 


fields like 





PartNuml 

PartNum2 

PartNum3 

PartNum4 

PartNum5 

Descrip 1 

Descrip2 

Descript3 

Descrip4 

Descrip5 

Price! 

Price2 

Price3 

Price4 

Price5 

Quantl 

Quant2 

Quant3 

Quant4 

Quant5 


and so forth. They posit that this wastes space 
because usually an order is either shorter than 
the maximum number of possible entries in a 
record, or is longer and thus needs an addi¬ 
tional record. 

First of all, FileMaker makes it easy to cre¬ 
ate a set of fields for a task like this. Rather than 
replicate independent fields over and over, 
FileMaker users take advantage of repeating 
fields that only need to be defined once and 
can then be used for up to 999 repetitions. This 
makes creating the fields easy. And by making 
the number of repetitions large we can accom¬ 
modate almost any order in a single record. No 


FileMaker designer would ever stop at five (or 
a dozen) repetitions if there was a reasonable 
expectation of some orders with more than five 
(or a dozen) items. 

Even without repeating fields, the same 
considerations apply except that it is a little 
more difficult to set the fields up. In both cases 
the Slide feature in FileMaker makes it easy to 
fold the rest of the invoice neatly around what¬ 
ever number of items are ordered. 

But does the large number of repetitions 
waste space since room is allocated for those 
extra fields? To find out I created three test 
files. Testl has a set of four repeating fields like 
those above, and with five repetitions each. 
Test2 is the same but with 999 repetitions. 
Test3 has the same basic fields but all are non¬ 
repeating and are simply independent (20 
fields instead of 4). I put one record of data in 
each, compressed all three and checked the 
resulting file sizes. 
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1 Record Test 

Testl 3,584 bytes (25K) 

Test2 3,584 bytes (25K) 

Test3 6,656 bytes (25K) 

(The number in parentheses is the space con¬ 
sumed in the Macintosh file system; all three 
take up the same space on the hard disk: 25K 
bytes.) 

It appears that the number of repetitions in 
a repeating field does not consume overhead. 
Test3 (with independent fields) takes up 1.86 
times as much pseudo-space as Testl or Test2. 
Remember, I said we only use a structure like 
the one in Test3 when, rarely, other circum¬ 
stance dictate. 

I don’t really see any ‘wasted’ space here. 
Indeed, I wonder if a relational program could 
be as space-efficient as this. 

OK, so maybe there would be bigger differ¬ 
ences with more data entered. I loaded in in¬ 
formation for 100 records, with varying data 
for each record (not just duplicates of the same 
data), and compressed again. 

100 Record Test 

Testl 37,888 bytes (49K) 

Test2 37,888 bytes (49K) 

Test3 41,472 bytes (49K) 

In this case Test3 takes up just 1 . 1 times the 
pseudo-space as Testl or Test2 — evidently 
the overhead for the independent field defini¬ 
tions is being swamped by the space used for 
the raw data. I still don’t see wastage. And re¬ 
member that all fields are indexed. 

Perhaps the authors are remembering the 
bad old days when records were fixed-length 
and consumed a defined amount of space in¬ 
dependent of their content. This was done to 
make life easier for the application program¬ 
mers, not the users. If you run into such a data¬ 
base now, tell it to go away. Modern databases, 
like FileMaker, are based on variable-length 


fields and records, removing another level of 
concern for the end-user. And, by the way, 
making storage space more efficient. 

(2) The second tell-tale sign for switching 
to relational is time wasted entering the same 
data over and over. Once again, no one really 
does what the authors have described as being 
characteristic of flat-file designs. For both File¬ 
Maker and Panorama no one reenters data any 
more than the relationals do. For a data-entry 
example in FileMaker there would always be a 
Customer file (one customer per record) that 
would be used as a lookup for the Order file 
(one order per record). 

Perhaps the relationalists have an aesthetic 
feeling that it is untidy for the customer data to 
actually exist in two places. Is this the source of 
their wastage worries? I suggest they get over it. 

Just to check on the impact, I made a file 
called Test4 that is a Customer file used as a 
lookup. I put 75 different names and addresses 
in its 14 fields, compressed it and found that it 
consumes 29,184 fully indexed bytes and takes 
up 49K of disk space. Add this value to the 
space tables above for a more complete con¬ 
text. There is nothing wrong with the data 
existing in two places. On the fringe, it even 
helps sometimes with data recovery. And there 
is no apparent penalty. 

1 

(3) The third tell-tale sign put forward for 
switching to a relational design is that the file is 
getting too big and too slow. Of course we 
don’t really know the definition of “too” for 
these attributes. FileMaker files can certainly 
get quite large — indeed, I know a few users 
who are bumping into the upper bound of 32 
MBytes. But I don’t think FileMaker files are 
particularly larger than other fully-indexed 
databases. 

Panorama keeps tons of data in extremely 
small files, much smaller than a relational data¬ 
base could hope to accomplish, and operates 
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very quickly. If you are really hung up on file 
size and/or speed, why bother with a relational 
when you could use Panorama? 

In addition, with FileMaker at least, most 
solutions for complex problems are subdivided 
into several files that work together, helping to 
keep individual files smaller. There are also 
straightforward techniques (many explored in 
The FileMaker Report) for off-loading func¬ 
tionality into separate files as external func¬ 
tions. This means that files usually remain 
modest in size, crisp in execution, and simple 
to design. 

But even when my files do get “big” and/or 
“slow”, I am still not inclined to change. Abso¬ 
lute storage minimization is simply a minor 
consideration. The price to be paid for some¬ 
times modestly smaller files is a big investment 
in programming and in hassle. And fast hard 
disk space gets less expensive every day and 
represents a good way to spend the money that 
would otherwise be consumed trying to con¬ 
vert. Similarly, if response time is a productivi¬ 
ty issue, it soon becomes clear that money 
spent on faster hardware provides a good re¬ 
turn on investment. Joe’s Rule #810: Spend 
RAM and hard disk space when you get a good 
return for it (like FileMaker’s efficiency). 

More Rebuttal 

• It is true that a relational database is not 
limited to a single record structure and that this 
is a good characteristic. But the implication 
that FileMaker is so limited is not warranted. It 
is quite common in FileMaker to use two (or 
many) files tied together with simple lookups 
and simple scripting to display and indepen¬ 
dently manipulate various portions of the data 
and sometimes multiple sets of the same data. 
And this can all be done across a network and 
with both Macintosh and Windows platforms 
as well. 

• Rich and complex programming in rela- 
tionals allows sophisticated data integration. 


Straightforward calculations and scripts with¬ 
out complex programming allow sophisticated 
data integration in FileMaker. Take your pick. 

• FileMaker forms are not inherently “un¬ 
professional” because of “blank fields and 
duplicate records.” The FileMaker Slide com¬ 
mand gets rid of blanks easily. Using multiple 
layouts and/or data-driven layout techniques, 
forms can be created that are completely 
adapted to the specific data in every record. 
Besides, I’ve seen lots of messy relational lay¬ 
outs. Joe’s Rule #811: ugly abounds in every 
clime. 

• Speed differences between Application 
Generators and Hierarchicals are not always in 
the relationals’ favor. When they are, the differ¬ 
ences are often minor or unimportant to the 
task. If important, speed is much more cheaply 
bought with hardware or architecture changes. 
In the real world, a PowerMac running File¬ 
Maker Pro Server, for example, exceeds the 
needs of all but a few rare cases. And if the last 
ounce of speed is vital why go to a relational 
when Panorama is available? 

• The step up to ‘relational’ products is 
huge in time, treasure, and dependence on a 
specific developer. There are many abandoned 
relational projects out there. The story behind 
each is often the same - the program never 
seemed to get finished, never worked the way it 
should, never was available for the user to make 
changes without the programmer. 

The villain in most such cases is really that 
you must do real programming. That means 
you can create real bugs; and because you can 
‘do anything’ with these programs, you try. 
Users interested in getting real work done, 
rather than becoming programming hobbyists, 
should stick with a good hierarchical database. 
The other products are really developer tools. 

With FileMaker at least, even when you 
need a consultant for the setup, it remains 
reasonable for the user to make modifications. 
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The last line of the article (quoted in the 
“Article Summary” box) is just backwards — 
my experience is that switching will likely gen¬ 
erate frustration, cost plenty money, disrupt 
your office, and make you doubt your sanity. 
But it should be good business for FileMaker 
and Panorama consultants as they rescue users 
from their attempts to switch. 

If you are actually thinking of switching, try 
these real-world tips as a first-aid kit. 

• Lie down until the inclination passes. 

• Make sure your evaluation of your cur¬ 
rent files is realistic. If they are working and 
productive don’t be intimidated by those who 
sneer. 

• Make yourself list the actual reasons you 
are inclined to make a switch. Make sure those 
reasons are what you will really end up with. If 
a dominant reason is that you just want to be 
able to say proudly that you are working with a 
“relational” database, be willing to admit it to 
yourself. Then, if you have to, consider saying 


that you installed a new extension that makes 
FileMaker relational (that is, lie about it). 

• Pretend there are no relational databases. 
Restate the problem in a way that FileMaker or 
Panorama can handle. Relational proponents 
seem to constantly, and falsely, state database 
tasks so that they can only be solved with rela¬ 
tional tools. 

• Learn to read beyond the manual. The 
official feature set of any program is only a 
starting point. Seemingly minor features, like 
FileMaker’s often-maligned repeating fields, 
can do amazing things when used imaginatively. 

• If you assume you need relationaiity, start 
the project by modeling the solution in File¬ 
Maker, as many people do since it can be done 
quickly and easily. Plan to move later to a rela¬ 
tional database after the system and procedures 
are debugged. But you won’t move since it can 
all be done in FileMaker, and nicely. ""V* 

Mike Harris ofWaterTechnics 
contributed to this article. 


A Relational FileMaker? 

I do not know what they are really doing, but the rumors are that Claris might be close to adding 
relational capability to FileMaker. If so, will it show up as a separate product or integrated into FileMaker? 
Unknown. Will it maintain the smooth, end-user-oriented interface of the rest of FileMaker? Unknown. 
Will we have to program procedures to use it? I trust not. Will it let us do more than we can do now or 
will it just offer alternative methods for what we already accomplish? Unknown. Will we use it or will we 
be tempted to ignore it and stick with our current techniques? Unknown. 

But assume for the moment that (a) it happens, and (b) it turns out to be quite nice. Then on the 
spectrum of database capability, how far away from the top will FileMaker, already multiuser and multi- 
platform, be from the pinnacle? The relational snobs won’t have FileMaker to kick around any more! 
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FileMaker Version History 

Version 

Release Date 

FileMaker Pro 2.1 v3 

July 1994 

FileMaker Pro 2.1 v2 

February 1994 

FileMaker Pro 2.1 vl 

August 1993 

FileMaker Pro 2.0 v4 

April 1993 

FileMaker Pro 2.0 v3 

February 1993 

FileMaker Pro 2.0 v2 

November 1992 

FileMaker Pro 2.0 vl 

October 1992 

FileMaker Pro 1.0 v3 

March 1992 

FileMaker Pro 1.0 vl 

October 1990 

FileMaker 4 & FileMaker II 

July-October 1988 

FileMaker Plus 

August 1986 

FileMaker 1.0 

May 1985 


(Minor revisions were not tracked before FileMaker Pro. 
Most minor changes are available almost free. Some are 
released to address only a specific usage.) 

About Claris 

Claris Corporation publishes the FileMaker program. 
The general address for Claris is: 

Claris Corporation 
PO Box 58168 
Santa Clara, CA 95052 

Add mail stops to the general address as appropriate. 

Customer Assistance: M/S C-11 
Technical Assistance: M/S C-12 
Software Registration: M/S C-71 

The general Claris phone number is 408-987-7000. 
Claris Customer Assistance is 800-325-2747. 

Claris Support recorded help line is 800-735-7393. 
Claris Support Fax line is 800-800-8954. 

Claris BBS is 408-987-7421 (settings 8/N/l). 

Claris Technical Assistance (Mac) is 408-727-9054. 
Claris Technical Assistance (Windows) is 408-727-9004. 
Technical Assistance hours (Pacific Time) are 6 am to 
6 pm Monday - Thursday and 6 am to 2 pm Friday. 



